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A LITTLE PEP TALK 



Over the past couple of years R51/CADRE 
^as been experimenting with computer soft- 
ware for cluster analysis. Six programs, 
implementing nine clustering algorithms, 
have been acquired from outside the Agency and 
modified for use on CDC 6600/7600 computers. 

These clustering methods are data- dependent, 
i.e, the model most suitable for a specific data 
set will depend on the form and nature of the 
data. The intent of the analyst must also be 
a consideration. (For example, does the investi- 
gator wish to find natural groupings in the data 
or to partition the data base into a predeter- 
mined number of categories?) It may be neces- 
sary to try several clustering methods on the 
same data to determine the most appropriate 
algorithm. 

PEP-1 (Probability Evaluated Partitions, 
version 1) is one of the six clustering programs 
that R51 has adapted for Agency use. PEP-1 
converts a set of input vectors into a matrix 
of pairwise similarities (or dissimilarities) 
(see Fig. 1). The choice of similarity (or 
dissimilarity) measure is an option of the pro- 
gram. The user may select any of the following 
measures: cross I.C. values, dot products, 
normalized dot products, Euclidean distances, 
and city block distances. The choice of mea- 
sure must be guided by the nature of the real- 
world problem and the intent of the investiga- 
tor. For example, does the analyst wish to 



The entry in this cell measures 
the strength of the relationship 
between objects d and o. For 
similarity data, the higher the 
value, the stronger the associa- 
tion. For dissimilarity data, 
the lower the value, the stronger 
the association. 

Fig. 1 Similarity Matrix on Five Objects 




match peaks and valleys in the vector profiles 
or, instead, match numerical values in corres- 
ponding components? 

It should be mentioned that the analyst may 
construct his own similarity (or dissimilarity) 
matrix and then input the result into PEP-1. 

PEP-1 orders the matrix entries from highest 
to lowest and replaces the numerical value in 
each cell with its rank order. (Tied entries 
receive the same rank order.) The PEP-1 algo- 
rithm can best be understood by regarding the 
entities to be clustered as vertices of a com- 
plete graph (i.e., an edge joins every pair of 
vertices) (see Fig. 2). The edge connecting 
any two vertices is identified with the entry in 
the similarity matrix which measures the strength 
of the association between those entities. 
b 




P.L. 86-36 



Fig. 2 A Complete Graph on Five Vertices 

PEP-1 sequentially deletes edges from the 
complete graph according to the rank order of 
the entries in the similiarity matrix (the 
edge corresponding to the weakest association 
is removed at each step of the algorithm/ 
multiple edges are ridded in the case of ties) 

9 k 



m 



Fig. 3 



Removal of the edge joining 

h and j produces a disconnected 

graph consisting of two clusters 
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until a disconnected graph is produced. At 
this point PEP-1 publishes the two partitions, 
the similarity (dissimilarity) value where the 
split occurs, the rank order of this value, 
and a "probability" that the disconnection 
could happen at random. The PEP-1 probability 
is merely an estimate (the true combinatorial 
probability is very complicated to compute] 
and is to be used only as an analytic aid to 
give a general impression of cluster validity. 
PEP-1 then reapplies the algorithm to each par- 
tition until the number of entities in a parti- 
tion or subpartition is less than six. 



Real-world 
problem 



T 

\Tke analyst must know 
\what to measure to make[ 
\the data reflect the 
\veal-world problem 



Data 



\The analyst must make 
\an appropriate choice 
\of similarity (dis&imi- 
\larity) measure 



Matrix of simi 
larities (dis- 
similarities) 



The analyst may choose 
another clustering al- 
gorithm at this stage 



PEP-1 



A 



Cluster output 
and splitting 
probabilities 



Internal disposition 
of the investigator 
and his knowledge of 
the real-world problem 



Integration of 
information 



Cluster solution 



Fig. 4 The Clustering Process, Showing 
the Interaction (in Italics) of 
the Analyst and his Algorithm 



It should be emphasized that the analyst 
is unable to prescribe in advance the number 
of clusters to be found by PEP-1 or the thresh 
old levels at which the splittings occur. 

PEP-1 is a reasonable choice for a cluster- 
ing algorithm if the following conditions are 
satisfied: 



the analyst wishes to cluster a similar- 
ity (dissimilarity) matrix of his own 
construction or feels that he can select 
an appropriate measure to derive simi- 
larity (dissimilarity) data from vector 
input ; 

the analyst seeks to determine natural 
clusters in his similarity (dissimilar- 
ity) data matrix; 

the analyst requires some numerical in- 
dication of the quality of the cluster- 
ing produced by an algorithm; 

the analyst wishes only the rank order 
information in his similarity (dissimi- 
larity) matrix and not the numerical 
values themselves to determine cluster 
structure; 

the analyst is aware that PEP clusters 
are not necessarily compact and may, 
in fact, be serpentine or sausage- 
shaped (see Fig. 5); 

the analyst wants an algorithm that 
will not be harmed by the presence of 
outliers (deviant observations) in the 
data; 

the analyst wishes to cluster fewer 
than 100 entries (fewer than 128 on 
the IBM 370/65). 





Fig. 5 PEP-1 clusters may assume a 
variety of shapes 

If you have any questions about cluster 
analysis or about the possibility of applying 
clustering techniques to y our operationa l prob- 
lem, please co ntact eithe r |~ | (Chief, 
R51, 8518s) or | ~~ | (R51, 8626s). ^ 
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or some time now, the subelement manager 
has been engaged in a battle to defend 
his resources against reductions initi- 
ated for a number of reasons. Managers 
at all levels have been barraged by a series 6f 
statistics designed to aid in making resources- 
reduction decisions, to show the efficiency of 
collection resources, to determine the cost of 
product reporting, and to allocate the resource 
expenditures for each function within the sub- 
element of interest. The usefulness of statis- 
tics as a tool for making these types of deci- 
sions has been widely accepted, the accu- 
racy of the statistics is rarely questioned and 
many decisions are based solely on this data. 

The current period of dwindling resources and 
rising inflation, with the concurrent review of 
intelligence expenditures, has created an in- 
creased dependence on statistical methods as a 
means of determining efficiencies of operation. 
Aided by a myriad of computers providing a capa- 
bility to count and measure that was never 
before possible, statistics have emerged as the 
guardian of our expenditures, the protector of 
our resources, and the practically omnipotent 
champion of efficiency. Savings have been made 
and some very necessary trimming of fat has re- 
sulted. These are significant accomplishments 
and speak well of the systems we have created. 

Statistics, by definition, is a branch of 
mathematics dealing with the collection, analy- 
sis, interpretation, and presentation of masses 
of numerical data. The compilation of statis- 
tics requires a collection of quantifiable data. 
Only those things which can be measured or 
otherwise quantified can be considered when con- 
structing statistics. In measuring SIGINT pro- 
duction, the statistician must therefore look 
at such things as the number of COPES objectives 
satisfied, the number of minutes of copy by 
case, the number of products produced, the 
number of intelligence requirements satisfied, 
or some other similar quantifiable data. 

This has caused great difficulties for some 
subelement managers when defending their re- 
sources and has caused us to overlook one of 
our greatest intelligence contributions, which 
I call negative intelligence. Negative intel- i 



ligence is the intelligence gained from knowing 
that a target unit is performing normally or is 
perhaps inactive. P 



Statistics, as most statisticians will 
admit, can be used to show whatever the statis- 
tician desires. Remeirtber the old "Figures 
don't lie, but liars figure" adage? E Jo ;jguard( c j 
against this, in our very important sourg.&s_ ^ g 
area, it is necessary to temper statistically 
suggested resource reallocations with consider- 
ations of the negative intelligence not reflec- 
ted in the statisticians' figures or to devise 
a method of measuring negative intelligence 
contributions. Until we can do that, we must 
rely on the analysts to provide qualitative 
judgments through the subelement manager. The 
importance of these qualitative judgments can- 
not be overemphasized and they must be con- 
sidered along with the statistical inputs. 
Granted this makes assessments subjective to a 
point and renders decision-making more diffi- 
cult, since decisions cannot be made solely on 
a quantitative basis, these assessments 
nonetheless can provide the information neces- 
sary to protect that important negative intel- 
ligence data which may be irretrievably lost 
in a primarily quantitative evaluation. Remem- 
ber that what we don't get is also important. 
In many cases we must accentuate the negative. 
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T- his paper will describe Remedial Soft- 
ware Engineering, a systematic approach 
to identifying design deficiencies in 
software systems and implementing im- 
proved systems economically. I will combine 
ideas previously published by Yourdon, Metzger, 
and other authors to produce a methodology for 
dealing effectively with "problem 11 systems. I will 
give no detailed explanation of software design 
methodologies but will assume that the reader 
either is familiar with them or will consult the 
references for clarification where necessary. 

Peter Prescription #36 asserts that rational ac- 
tion must be based on answering thTee questions: 

1. Where am I? 

2. Where do I want to be? 

3. How do I know I am getting there? 1 

This paper will explain how to use proven tools 
and techniques of software design and project 
management to answer these thTee questions. It 
is based on my experience with some small- to 
medium-sized NSA systems where these principles 
have been applied successfully. I leave it to 
the reader to decide whether or not Remedial 
Software Engineering might be applied beneficial- 
ly to very large projects. 

I chose the term ''Remedial Software Engineer- 
ing 1 (RSE} for three reasons. First, to imply 
that its application would be to a system for 
which some pieces have already been created, 
but which needs further work to be made useful. 
Secondly, to distinguish it from any particular 
software design or project management methodolo- 
gy. And, thirdly, to imply some measure of " or- 
derliness in the craft of rescuing systems from 
disaster. Equally suitable titles for the dis- 
cipline described below might have been "Crea- 
tive Software Salvage" or "What to Do When Disaster 
Overtakes Your Software Development Project." 

How Did I Get Here? 

The premise of this paper is that the answer 
to Peter's first question, "Where am I?", is, 
"In charge of a software development project 
which is in deep trouble." A quick review of 
some basic causes of project failure will lay 
the foundation for the RSE methodology. 

One major source of trouble is the lack of 
any system design. If nobody understands what 
is being built, then it follows that nobody 
will be very successful in trying to build it. 
Another source of trouble is a design that 
will not satisfy the real requirements. In 
this case, the implementers know precisely 



1 Laurence J. Peter, The Peter Prescription 
(New York: Bantam Books, 1972), p. 159. 



Reprinted from Proceedings: CISI Spring Conference, 
23-26 May 1977 (Computer and Information Sciences Institute* 
national Sec urity Agency. May 1977) , S-217-661, 217 pp., SC. 

I paper was awarded First Place among the Confer- 
ence Awards presented by Mr. Kermith H. Speiennan, Assistant 
Deputy Director, Telecommunications and Computer Services, 
in the Friedman Auditorium on 23 June 1977. 

what they are building. What they don't know 
is that their product will never perform use- 
ful functions for the customer without major 
remedial action. 

A second cause of disaster has to do with 
the project plan rather than the system 
design. The system design is a detailed blue- 
print of all the elements of the system being 
built and their interrelationships. The proj- 
ect plan, on the other hand, is a step-by- step 
description of how the pieces of the system 
will be assembled, unit-tested, integrated, and 
tested as a system. Where the system design 
specifies precisely what will be built, the 
project plan details how it will be built. If 
a project plan is missing or if it omits key 
considerations, serious problems will result 
and will frequently manifest themselves as 
apparent hardware or software design problems. 
If a house-building plan calls for installing 
the roof before laying the foundation, it is 
almost inevitable that the house design itself 
will be attacked by the carpenters as being 
unworkable. The plan and the design will then 
be modified on an ad hoc basis to make possible 
the immediate tasks at hand. Usually there 
will be no distinction made between the plan 
and the design. 

A third class of problems results from 
failure to follow the plan. For example, the 
system in trouble might have the wrong amount 
or the wrong kind of staffing even though 
the plan spells out exactly what staffing is 
required. Assigning 25 troglodytes to build a 
condominium is unlikely to produce a livable 
structure even though the cavemen are handed a 
set of detailed blueprints and an hour-by-hour 
description of the thousands of subtasks re- 
quired. Assigning 4000 architects to the 
project, again with perfect design and planning 
documentation, might yield similar results. 

Although Remedial Software Engineering is 
called for when development efforts run into 
trouble, there are other times when the appli- 
cation of the same principles might be benefi- 
cial. For example, if a functioning system is 
about to be upgraded to incorporate new hard- 
ware or software such as microprocessors, data 
base management systems, etc., the methodology 
detailed below might be an excellent prepara- 
tion for the conversion. Similarly, a system 
may be producing acceptable results but only at 
an excessive software-maintenance cost; RSE 
could help reduce the costs. In short, use 
Remedial Software Engineering whenever the pain 
associated with your current software efforts 
seems to be unbearable. 

In these introductory paragraphs I have 
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defined Remedial Software Engineering, stated its 
purpose, and suggested when its use would be 
appropriate. In summary, I quote the author 
of Patterns of Problem Solving, who said, "The 
most common difficulty in problem solving is 
not lack of information, but rather the failure 
to use information that the problem solver* 
has." 2 The remainder of this paper details 
three phases of making systematic use of the infor- 
mation on hand to answer the three questions of 
Peter Prescription #36 and convert incipient 
software disaster into a productive system. 

Where Am I? 

First, gather the current requirements for 
the system you are seeking to build or modify, 
and design an "ideal" system against those 
requirements. Ignore for the moment the pieces 
of software you already have, even if they are 
"unit tested" and function perfectly. Use any 
structured design methodology of your choice 
and apply it rigorously. Various groups, some 
at NSA, have applied HIPO, Transform Analysis, 
Transaction Center Analysis, and Jackson Design 
methodology 3 with success. It appears as 



2 Moshe F. Rubinstein, Patterns of Problem 
Solving (Englewood Cliffs: Prentice-Hall Inc., 
1975), p. 8. 

3 See: Edward Yourdon and .Larry L. Cons t ant ine, 
Structured Design (New York: Yourdon Inc., 1975) 
for a discussion of the first three methodologies. 
See also: The Jackson Design Methodology, Info- 
tech International Handbook (Pasadena, 1977) . 



though the particular tool used is not as impor- 
tant as the fact that some technique is applied 
uniformly and rigorously across the whole sys- 
tem. 

Fig. 1 is an abbreviated structure ,chaTt of 
a segment of a hypothetical system which must 
gather some data and display it on a terminal, 
among other things. Note that all functions 
are broken down into the smallest possible com- 
ponent parts and that all data flow and control 
are explicit. You can trace the flow of solid 
arrows to see where the data goes and how it 
gets changed along the way. Each module has a 
single function. The modules may be combined 
together in-line to form a single program, 
they might be a mix of separate programs and 
subroutines, or they might even be a mix of 
hardware, firmware, and software. The point 
is, the structure chart ignores all those con- 
siderations and concentrates on the elements 
of the problem solution only. Once they are 
understood, then intelligent decisions can be 
made separately about how to package the modules. 

You may have to resist a great deal of 
pressure to skip this step. There are still 
some people lurking about NSA who will try to 
persuade you that time spent drawing pictures 
is wasted. (I suspect such characters pervade 
many institutions in the private sector, too, 
although I only deduce this from the work de- 
livered by some contractors to NSA.) These 
people advise that we start attacking the prob- 
lems directly, even though some symptoms may 
be half -recognized. Indeed it seems as though 
each of us tends to have a deep-seated urge to 




* This paper will use several of the Yourdon definitions 
and conventions. Among them are: 

Solid-tailed arrows represent data, 
Hollow-tailed arrows represent flags. 
A box represents a module. 

Arrows into a box interior indicate data flow into 
the middle of a module as opposed to through 
the module's entry point. 



A module is any lexically contiguous set of 

computer instructions. 
Atomic modules are the lowest-level modules. 
A straight line represents one module invoking 

another module. The higher invokes the lower 

unless otherwise noted. 
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start modifying code too soon. 

Just remember that design is cheaper than 
fabrication. It is an abstraction which can be 
manipulated easily without intervening distrac- 
tions such as the hardware peculiarities, 
operating system vagaries, or programming- lan- 
guage oddities. If done properly, the structure 
of the design will very closely depict the 
structure of the actual problem to be solved. 
You will probably find that someone who has 
not had a hand in creating the. mess you are cor- 
recting will be extremely helpful during this 
design phase. Being uncorrupted by the faults 
of the existing software design, he can give a 
more objective opinion of the "fit" between 
your "ideal" system design and the problem to be 
solved. The trick is to keep yourself and your 
team from corrupting him! 

You must now document the existing system 
design using the same notation you used for 
the design of the ideal system. If you cannot 
document the design of the existing system, 
then you should decide to replace it in its 
entirety. In this case, you might be able to 
salvage some code from the old system modules 
as described below. This activity can be very 
dangerous, however, since you might preserve 
some of the major causes of your troubles. 
By saving only atomic modules and resisting 
the temptation to add code to them, you can 
protect yourself in most cases. 

Now that you have two system designs, the 
old and ideal, lay them side by side and com- 
pare them. You should look for correspondence 
between the two designs. You might even 
have some modules from the old design that have 
already been coded and can be kept as is 
because they match the ideal design perfectly. 

You are likely to have some modules that 
should be replaced because they are "corrupt" 
in design. The lack of correspondence will be 
seen as confused flow of control and inconsis- 
tent interfaces with various superordinate mod- 
ules. The modules will also mix several func- 
tions without justifiable purpose. 

Fig. 2 shows a possible representation of the 
existing design documented using the same con- 
ventions as the ideal design in Fig. 1. Notice 
that the data display portion of the system con- 

MAIN 



CONTROL 
THE 
SYSTEM 




MERGE DATA AFTER 
FORMATTING IT 
WHILE GATHERING 
IT AND DISCARDING 
GARBAGE; THEN 
DISPLAY IT 



PROCESS 
EVERYTHING 



Fig. 2 



sists of a single module with the functions 
hopelessly entwined. This characteristic prob- 
ably was due to a bad system design before the 
software implementation began, or perhaps the 
design was not understood or followed. When 
confronted with hopelessly corrupt modules 
such as the data gathering/displaying one in 
Fig. 2, you should salvage whatever atomic mod- 
ules you can and then throw the remainder of 
the code away. 

Fig. 3 depicts how you might be able to ex- 
tract the coding to construct your ideal "Send 
to Terminal" and ",Format a Line" modules from 
the existing mess. Very likely, all the other 
functions are so dispersed and mixed up that 
you will be able to salvage nothing else. 



I FORMAT THE DATA 





MERGE DATA AFTFR 


< 


, IWHILE 


1 GATHERING IT AND 
[DISCARDING GARBAGE: 


IthenI 



Fig. 3 



I DISPLAY IT I 



You might also find some modules in the 
existing system that are moderately corrupt but 
have been performing satisfactorily for some 
time. These represent a real problem, par- 
ticularly if you find yourself in the same 
tight resources situation as the rest of the 
world. You will be tempted to keep them and 
thus corrupt your ideal system design. In- 
deed, you might have no choice but to keep at 
least some of them because of the lack of 
time, money, or people. 
Where Do I Want to Be? 



You have already documented where you would 
like to be in a Utopian world when you designed 
an "ideal" system. But now you must reconcile 
your ambitions with the reality of limited re- 
sources. You must answer Mr. Peter's second 
question by defining revisions to the software 
system that make the best possible use of the 
software already implemented as well as new 
software to produce a reliable and useful 
system. 

If you keep any poorly-designed modules, you 
must recognize that you are doing so and realize 
the possible consequences. The cost of main- 
taining those modules will be excessive for 
the life of the system. They might contaminate 
the rest of your system if you do not take 
positive" steps to prevent it. They might 
not even be functioning as well as you think; 
perhaps they just have not yet had sufficient 
opportunity to fail. They might come back to 
haunt you at a critical point in the project. 

A more subtle danger in using admittedly ■ 
corrupt modules is that members of your team 
might perceive a lower set of standards for the 
software project than you intend. Actions 



April 78 * CRYPTOLOG * Page 9 



UNCLASSIFIED 



DOCID: 4009810 



UNCLASSIFIED 



speak louder than words. If you retain sub- 
standard modules from the old system, make 
sure that every member of your team understands 
that you know they are substandard, that you 
have weighed the risks, and that you kept the 
modules for very specific reasons. Emphasize 
that the modules are substandard m and that you 
will accept no new modules of similar quality. 

You should insulate all substandard modules 
from the rest of the system with interim inter- 
faces that conform to all the standards of good 
system design. Figs. 4 and 5 show how this 
can be done. Module 3 is typical of modules 
that can be found in many systems. It has mul- 
tiple entry points; its logic depends on inter- 
nal flags set by external modules; it gets its 
data inserted into it by external modules; and 
it returns its results by placing data directly 
into the middle of the invoking modules. 
Let us suppose that module 3 has been stable 
for a considerable length of time under extreme- 
ly severe testing conditions and further suppose 
that to replace module 3 would take 12 man- 
months. Let us also suppose that you want to 
replace module 2, a one man -month job, and re- 
tain modules 1 and 3. 




Fig. 5 depicts the proper way to insulate 
modules 1 and 3 from the rest of your system. 
The interim interface module has single entry 
and exit points, and conducts its external 
communications (data and control) explicitly. 
Note that the new version of module. 2 uses the 
interface and follows all the rules of propeT 
intermodule communication, but that modules 1 



MODULE 1 



MODULE 2 



MODULE n 



INTERFACE MODULE*! 










Fig. 5 



and 3 are unchanged. You are now in a position 
to redesign at your leisure module 1 and any 
other modules which invoke module 1. You can 
also deploy new modules which invoke module 3 
through the interface without compromising their 
design because of deficiencies in module 3. 

After all the invoking modules have been con- 
verted, then module 3 itself can be reconstruct- 
ed. Fig. 6 depicts this last step. The inter- 
face module has become permanent with the .) 
assumption of controlling functions. An aTTay 
of subordinate modules has been created with 
each submodule performing exactly one of the 
functions from the original module 3. 



MODULE ) 




MODULE 2 




MODULE n 




FUNCTION 




FUNCTION 




fuNCTIftN 


1 OF OLD 




2 OF OLD 




3 OF OLD 


MODULE 3 




MODULE 3 




MODULE 3 



Fig. 6 

Another activity of designing is to incor- 
porate the best commercially available products 
wherever possible, rather than reinventing the 
wheel. If a portion of your system design calls 
for modules to manage data, consider using a 
commercially available data base management 
system. There are now several on the market 
which have given many customers satisfactory 
results'*. By using one of them, you can con- 
centrate your own personnel on solving the cus- 
tomer problems rather than the computer prob- 
lems. Consider also some of the newer hardware 
technology that is available. For example, some 
of your modules might be best implemented on 
microprocessors. When you complete step 2 of 
your remedial software engineering, you will 
have a complete design plan for your system 
including how each module will be implemented. 



^See: Herbert L. Gepner, "User Ratings of 
Software Packages, Datamation (December 1976), 
p. 108. 
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How Do I Know I Am Getting There ? 

You have compared the existing design to an 
"ideal" system based on the current requirements 
and devised a design for the system you will im- 
plement. Now you must plan the implementation 
effort and continually compare the actual prog- 
ress to the plan to answer the last of Peter's 
questions. 

Managing a Programming Project 5 is an excel- 
lent reference for use in the project -planning 
phase and I will not repeat in this paper every- 
thing Metzger says in his book. Several points 
deserve special emphasis, however, and Metzger 
touches on them only lightly. 

It is essential to match your resources to 
the task or vice versa. Remember the cave 
dwellers building the house? Assign the right 
number of people with the appropriate skills to 
the remedial software effort. Consider aug- 
menting your work force by contracting some 
pieces of the system to the private sector if 
you have' a surplus of money and a shortage of 
.people, or if some particular skills are 
unavailable to you directly. I know of one 
project, not at NSA, where the configuration 
management function was contracted successfully. 

If you cannot staff your effort properly, 
then scale down your ambitions and undertake to 
deploy a more limited system. If it is impos- 
sible to undertake less and still produce a 
useful and reliable system, then you should can- 
cel the project. To do otherwise would be a 
waste of taxpayer dollars. One project manager 
at NSA recently mused as he stood in the sham- 
bles of an overly ambitious and understaffed 
project, "If you are not big enough to take the 
bull by the horns, then the best you can pos- 
sibly hope for is to stay a few steps ahead of 
the beast as you run in circles around the ring. " 
He was right, only if you accept his assump- 
tions that his size and boldness were the only 
variables. But the bull could have been either 
, trimmed down in size or eliminated. Shrinking 
the bull would increase the project manager' s rel- 
ative size and executing the bull would allow 
the manager to tidy up in a leisurely manner 
before regrouping for the next fray. 

Having achieved the right match-up between 
the project size and staffing, make sure you 
provide your workers with all the tools they 
need. Dick Brandon, president of ACT-Brandon, 
recently said, "I am amazed today that we are 
working with 1975 hardware, using 1971 soft- 
ware, and managing as though it is 1960 and 
that we are trying to automate an organization 
with a structure designed in 1944. 1,6 Mr. Bran- 



5 Philip JV. Metzger, Managing a Programming 
Project (Englewood Cliffs: Prentice-Hall Inc., 
1973). 

6, 'The Computer As Villain," Datamation 
(April 1976), p. 14. 



don could have been studying NSA when he said 
that. 

Some of the tools that some managers give 
too little emphasis to are training, testing 
mechanisms, and standards. It is unfair to 
everyone involved to ask a newly hired college 
graduate or recently transferred computer 
operator to design, code, and test a piece of 
software for a computer he has never seen, in 
a language he knows nothing about, to solve a 
problem he only vaguely understands. Instead, 
he should be trained in the language he is to 
use; he should be handed a copy of the stan- 
dards his documentation, software, and- test 
plans are expected to adhere to; and he should 
understand the system design and project plan 
documentation. He should be working from a 
detailed functional description of the module 
or modules he is to produce. The functional 
description will include detailed descriptions 
of all interfaces between his software and the 
rest of the system. The system should have 
built-in trace and audit trail features to fa- 
cilitate debugging and testing. Given these 
tools, you can safely leave the detailed de- 
sign, coding, debug, and unit testing to the 
individual's programming team. 

One last point I would like to add to Metz- 
ger 's discussion of planning the project is 
to consider carefully your system implementation 
strategy. Harlan Mills of IBM has made some 
thought-provoking points about the working re- 
lationship between computer people and their 
customers. 7 He suggests that rather than dis- 
appearing for several months of coding and test- 
ing as soon as you have gotten the customer to 
sign a detailed requirements document, you should 
demonstrate another real piece of the system at 
least once a month. This would greatly reduce 
the understanding gap that frequently widens 
between the customer and the system implement - 
ers on many software development projects. It 
will help insure that misunderstandings which 
occurred during the requirements definition phase 
are surfaced early, before the whole system is 
coded and tested. Mr. Mills' arguments tend 
to be reinforced by my experience with several 
NSA projects and they suggest some guidelines 
for your implementation efforts. 

Getting There 

You have done your homework and rolled up 
your sleeves to begin the real work. Since your 
system design has been thoroughly tested in the 
abstract and you have a detailed project plan 
and you have even scattered all the right tools 
about your workers' domain, not much can possib- 
ly go wrong. Right? 

Wrong I 



7 Robert L. Patrick, "Software Engineering 
and Life Cycle Planning, Datamation (December 
1976), p. 79. 
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Remember, you are beginning your remedial 
software engineering effort at a low point on 
the project. Everyone has been working for 
3 years and seems to be no closer to putting a 
system into production now than when they 
started. Morale was low before you walked in, but 
now the requests for transfer are outnumbered j 
only by the volume of help-wanted ads being 
clipped from the newspaper. You will have to 
manage the remedial project better than any 
other project you have worked on. 

Metzger covers most aspects of managing the 
remedial software effort in his chapter, "The 
Programming Phase." 8 If you heed his advice 
on organizing your effort, dealing with changes, 
monitoring and controlling the work, and carry- 
ing the water for your subordinates, you will 
be in pretty good shape. Since the premise of 
this paper is that the project is already in 
the middle of the programming phase (or even the 
test phase) a few additional points should be 
made. 

First, you are likely to encounter great 
resistance to change. You will find that some 
optimistic members of the project team are 
caught up in the "light at the end of the 
tunnel" syndrome. They will insist that the 
successful completion of the system is in sight; 
just a few more corrections and a little extra 
effort will save the system. Of course, they 
have been saying this for months and have been 
reporting the system as 95% complete for 
about 50% of the elapsed project time. They 
are expending all of their energies on trying 
to make whatever code they have work. They 
never stop to seriously consider that their 
system design might be unworkable, either from 
basic flaws present from the outset or because 
the design has been seriously corrupted during 
the implementation. 

The trick is to convince them that things 
are really as bad as you know they are. Some- 
times a suspension of coding/debugging/testing 
and the assignment of a design analysis task 
culminating in a written report will do the 
trick. Some people will even see the light if 
you brief them on your own analysis of the 
existing design. Sometimes, though, you 
might have to simply pull rank on the indivi- 
duals and direct them to abandon their design 
in favor of your revisions. The result could 
be subordinates who are convinced that you 
sabotaged their good efforts just as they were 
about to bear fruit. You will not have their 
commitment to the revised system and their sup- 
port will be less than enthusiastic. It 
would probably be better to transfer to 
another project anyone who has such an enor- 
mous emotional investment in the unworkable de- 
sign that he refuses to listen to reason. 

you may also find that many of your program- 



8 Metzger, pp. 69-112. 



mers have become obsessed with creating "so- 
phisticated" code to the detriment of the sys- 
tem. This is a common problem, stemming in 
part from historical pressures to use every 
possible trick to cram many functions into the 
fewest memory locations possible. It might 
also stem from individual recognition that the 
current system design will never work and the 
"part of a successful team" reward will never 
materialize. The individual then internalizes 
his rewards by challenging himself to be 
even more clever in his production of code that 
will run faster in less core and do more work. 
The trouble is that nobody, including the ori- 
ginal creator, will be able to understand the 
code in 3 months when it has to be modified to 
allow for a requirements change. 

The solution to this problem is twofold. 
Orient every member of your team to the proj- 
ect objectives and build commitment from all 
to the development of a system that works. 
Also establish and enforce programming standards 
for the project. By ensuring that each indi- 
vidual understands the long-term benefits of 
never using part of an executable instruction 
as a constant, never using self-relative arith- 
metic, never hard-coding variables, avoiding 
GOTO's, etc., it will become easier for you 
to enforce the standards. Be sure to reward 
those who produce quality code as well as re- 
directing those who spend forever making a 
seldom-executed subroutine run faster, vio- 
lating standards in the process. 

Remedial Software Engineering: Summary 

Remedial software Engineering is the sys- 
tematic application of the best available soft- 
ware design and project management techniques 
to bring about desirable changes in software 
systems. RSE uses readily available informa- 
tion to analyze the current state of the sys- 
tem and implement an improved system. 

First, the remedial software engineer de- 
signs an "ideal" system to satisfy the require- 
ments of the customers and documents the design 
of the existing system with the same design 
notation. Next he compares the two designs and 
evaluates discrepancies between them. Then he 
resolves the discrepancies by designing a re- 
vised system which combines elements of the 
existing system, new elements, and some tempo- 
rary elements. Lastly, he manages the remedial 
project paying particular attention to the 
"people problems." 

By using a Remedial Software Engineering 
approach to problem systems, the project manag- 
er will make rational choices among explicit 
alternatives, lay the groundwork for productive 
team efforts, and bring the expectations of 
management, programmers, and customers into 
harmony with reality. He will have the manage- 
ment tools required to produce a quality 
product in a reasonable time. 
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NSA-crostic No. 13 



This month's NSA-crostic was 
submitted by guest NSA-crostician 
David H. Williams,. PI 6 



The quotation on the next page wae taken from an 

NSA publication. The first letters of the WEDS 

spell out the author's name and the title of the 
work. 



DEFINITIONS 

A. Feels clumsily 

B. Intellectual nourishment (3 wds) 

C. Russian man in the street 

D. Inside scoop 

E. Line from film by Word R, cited in 
Bartlett's Quotations, 14th ed. 

(5 wds) 

F. Industrial city in NE Ohio 

G. Emphasizes 

H. Pressure group 

I. "To be is some danger," 

Hamlet j Act III, Sc. iv (2 wds) 

J. "... of their appointed " 

K. Prolific motion picture director 
(2 wds) 

L. Reinforcing 
M. Erases 

N. Another line by Word R cited in 
Bartlett's Quotations 

0. Gemstone 
P. Eluder 

Q. Word K's fiftieth film, 1966 (2 wds) 



WORDS 
141 160 126 "53 

"T6 229 TT8 204 T89 133 176 ISO ~38 ~86 2l2 "65 T03 ~52 



69 58 127 112 61 207 
~8 55 163 "46 186 200 "95 
172^"20^l0^20T"^2l7"32T^ 

T05 ~4 5T 188 
~9~ 142 223 22T ~7T ~2T ~60 ~26 ~12 168 
183 149 ~3T 177 ToT 23l 119 H ~78 ~lA "93 
"24 T39 106 135 "50 
~TT ~1iT ~Tf 132 TUT 224 199 
"64 "90 ~T~ 16l 192 

~ZU ~T9 2L8 "39 181 "73 "94 ~17 227 ~56 TOO L46 ~~48 

TlO 

213 ~37 144 173 230 138 129 ~98 208 171 123 ~2 96 
l3l "84 "36 ~L3 120 l55 222 

196 175 ~91 104 "T8 ~5~ 209 137 187 ~68 164 "4l 2l9 "47 

T22 20T ~7S 148 193 ~T0 156 "99 
107 "67 T82 152 
195 ~T4 Tl6 206 T02 166 ~33 

"54 143" 2l0 125 ~85~ ~22 ^42 185 17 226 T80 



R. Star of eleven films ("Every Day's a 

Holiday," "Night after Night," etc.), 170 80 162 97 

author of eight of them (1893- ) 
S. Vicinitv 

113 45 147 92 82 63 15 128 
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T. Question asked of the cook at the 
monastery* s fish- arid -chip stand 
(5 wds) 



U. Process of producing images by 
reaction of light 

V. Intermittently (3 wds) 

W. Answer to query in Word T (5 wds) 



220 49 59 101 211 202 72 28 108 62 136 114 3 174 



89 228 23 151 



6 194 66 198 111 216 27 81 158 130 157 



35 140 25 179 154 215 169 191 



70 124 7 43 184 117 190 145 178 197 225 87 29 19 



167 




(Solution next month) 
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iCONOCES BIEN LA GEOGRAFIA? 
Tony Melzer, D5* 




Cartografo / autor del texto en 
ingles; traducido en espaftol 
por Esteban Vermes. 



Tanteo 


0-8 


I'Muy malol 


9-12 


Talcualillo 


13-15 


Bastante bueno 


16-17 


IMuy bueno I 
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C.A.A. NEWS By W.E.S. 



Miy 1978 ftmtiw'ion Plmed 

As of this writing (February 1978) , it looks 
pretty firm that our featured speaker for May 
will be our #1 Member (see reproduced membership 
card). Watch for announcements about day and 
time. 



COMMUNICATIONS ANALYSIS ASSOCIATION 
THIS IS TO CERTIFY THAT 

l/APM B. R. Inman, USN 

is a member in good standing of this association 
for the year ending 31 December 19 1 & 



1 78 



Pre 




(0) 



Whit to do tot membets on PCS? 



CAA members who transfer to overseas jobs are 
continued on our membership rolls "free" (no 
dues) for the duration of their PCS tour over- 
seas. One of the things the CAA Board will be 
wrestling with this year is how we can extend 
the aims and goals and benefits of the CAA to 
people who are "off campus." We want to talk 
with those of you who have ideas about this. 
Have you been overseas and "out of touch"? What 
do you think the CAA can do to help people 
who are now in the situation you were in? ^ 

Meet out new president! 

Our new president is David W. Gaddy, a 
Cryptologist in D5. He earned his BA in U.S. 
History at the University of North Carolina and 
an MS in Intern ational Affairs at George Washing- 
ton University. [ 



His cryptologic experience has included as- 
signments as linguist, bookbreaker, reporter, and 
supervisor on a wide variety of problems and 
targets in Southeast Asia. He was selected for 
the Armed Forces Staff College, Norfolk, Virgi- 
nia, in 1967, and for the National War College in 
1971. 

Since his return from the War College, he has 
held various senior planning positions, includ- 
ing a tour at the Pentagon (NCR Defense) . He is 
currently Deputy Chief, Intelligence Community 
Affairs (D5). 



He is certified as a Linguist and 
Special Research Analyst. — e€d t 

. . .and out new president-elect! 

Our new president-elect is Francis X. Por- 
rino, Chief of Al, Office of Operations and 
Control. He has served in the cryptologic com- 
munity since 1951, first as an enlisted man in 
the Air Force Security Service, then i n several 
capacities as a civilian (since 1955) . I 



He has performed at all levels of management 
through Office Chief. I 



J has attended the 



National War College, has served on the staff 
of the NCRDEF, and has served as Chief, Al. 
Also, over the course of his NSA career, he 
has completed studies at the University of Mary- 
land, earning a BA degree in Government and 
Politics, and has served overseas in the Office 
J He has also been awarded 



EO 1 
P.L. 



4. (c) 

86-36 



the Civilian Meritorious Service Award, 

He is certified in TA and SR and has been a 
member of the SR Career Panel. (C CCO) 

How fo become $ membet 



P.L. 86-36 



CAA dues are $1.00 per year. You can get 
membership applications from any of the people 
mentioned in these CAA news items. Send the 
completed application and $1.00 to Tim Murphy, 
B09, 3W114. Then just sit back and watch your 
in-basket fill up with news bulletins and an- I 
nouncements about all the many and varied acti- 
vities and programs of CAA. / ^ 



Communications Analysis Association: 




President David Gaddy 
President-elect Frank Porrino 


3247 1 


Secretary 


l 




Treasurer 


Tim Murphy 


3791 


Board members 





Can 



a biographical sketch on 

member, I f a nd mention our Program 



icel I wanted to give 
our newest CAA Board 
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translators 



September 1* 



1977 



The following letter was Bent on 
September 14, 197? to the President 
of the United States by Royal L, 
Tineley 3 Jr. , President of the 
American Translators Association, 



Dear Mr. President: 

Please accept ray congratulations and sincere 
appreciation for your encouraging attitude toward 
the study of foreign languages and cultures as 
expressed in your letter of 29 June 1977 to Con- 
gressman Dante Fascell concerning the Helsinki 
Final Act. Let us hope that the foreign- language 
teaching profession has learned its lesson from 
the 1960s and will make better use of future 
support by the Federal Government. I am a dedi- 
cated teacher of German (and sometime Russian 
teacher), but it is not as a teacher of foreign 
languages that I am writing this letter; you will 
no doubt receive enough letters from my col- 
leagues in the profession. 

Rather, as President of the American Trans- 
lators Association I am deeply concerned about the 
future of the translating profession in this 
country. Although the study of foreign languages 
is critically important for the welfare of the 
U.S., no one can learn more than a few languages, 
and most will do well to acquire minimal compe- 
tence in even one foreign language. Anything 
the individual learns about all the other cul- 
tures must ultimately be learned through the 
medium of translation. 

You are more aware than most Americans, I am 
sure, that the United States is no longer the 
world leader in several scientific and technical 
fields. This is no catastrophe, in itself, for 
surely every nation should have the right to ex- 
cel at something. I think you will agree, how- 
ever, that unless our American scientists and 
technicians can keep abreast of the latest de- 
velopments in their respective specialties there 
is, at the very least, undesirable duplication of 
effort and waste of time, energy, and money. 
Translation provides the only feasible means by 
which we can keep up with developments in all 
areas of the world. 



Reprinted by permission of "The ATA 
Chronicle, " newsletter of the American Trans- 
lators Association, P.O. Box 129, Croton-on- 
Hudson, N. y. 10520. 



In recent years there has been much duplica- 
tion and waste even in the vital area of techni- 
cal translation. Cover- to- cover translations of 
foreign technical journals often provide trans- 
lation of worthless material along with the cru- 
cially important. There should be a screening 
process for each discipline whereby leading ex- 
perts in the field would select important arti- 
cles and books for translation by competently 
trained translators. 

The latest developments in science and tech- 
nology are now being published in more than 70 
languages of some 100 countries. Even though 
English still accounts for about 45% of this 
material, and another 35% is published in Rus- 
sian, German, and French, some 20% appears in 
the less-well-known languages. The information 
value of Japanese publications has increased 
remarkably over the past few years, while Hun- 
garian has become very important for electron- 
incs, Swedish for metallurgy, power engineer- 
ing, and communications systems, and Finnish 
for woodworking, pulp and paper technology, 
icebreaker construction, etc. Polish, Czech, 
Bulgarian, and Rumanian technical literature 
is also becoming important, as is Spanish and 
Portuguese. When an agreement is finally 
reached that will permit us access to the tech- 
nical literature of the People's Republic of 
China we shall have several decades of develop- 
ment to study, and there is less than a handful 
of people in the United States today who are 
competent to translate technical Chinese. 

The number of translators in the Federal 
Government has been steadily reduced over the 
past several years. The shocking state of af- 
fairs in government translation was described 
by Richard S. Relac in a report in The Federal 
Linguist, Vol. 6, No. 1-2 (Summer 1974). In 
what was presumably intended as an economy 
measure, government translators were progres- 
sively phased out by elimination of jobs and 
by refusal to replace personnel lost through 
death or retirement. Many simply resigned be- 
cause they were given GS ratings below those 
specified for the positions and were denied 
promotions. Government translation needs were 
supplied to an increasing degree by contractors 
who received the work on a low-bid basis. 
Despite claims to the contrary by government 



April 78 * CRYPTO LOG * Page 18 



UNCLASSIFIED 



DOCID:" 400981^ 



UNCLASSIFIED 



procurement officers it can be documented that 
this procedure resulted in an incredible waste 
of money for a large number of marginally use- 
ful or completely worthless translations. Most 
professional translators either refused to 
work for the ridiculously low rates paid by 
the contractors or, in some few cases of which 
we are ashamed, they simply did not spend the 
time and effort necessary to do a professional 
job. The contractors were forced to recruit 
students, immigrants, war brides, etc., in 
order to meet their commitments. Some of .these 
people did indeed become competent translators 
in time, but at a staggering cost to the tax- 
payers! 

Mr. Lester C. Benefeld, Jr., Director of the 
Foreign Language Research Branch of the U.S. 
Army Foreign Science and Technology Center, 
was questioned during a meeting at Georgetown 
University in 1975 about the quality of this 
contract translation. Mr. Benefeld answered 
that most of these translations would never be 
used, and that it was sufficient, in any case, 
if the Army's scientists and technicians 
could deduce from the equations, tables, and 
graphs what the article was about! One wonders 
why the government should have paid even low 
rates for translation that apparently was not 
needed. 



"Shocking state of affairs in 
government translation. " 



In July of this year an official of the U.S. 
Bureau of Reclamation in Denver stated that there 
are government scientists and technicians who 
honestly believe that their Russian and German 
counterparts are incapable of writing under- 
standable reports of their own experiments be- 
cause every translation these American techni- 
cians have tried to use has been virtually 
incomprehensible! Competent professional trans- 
lators do not turn Russian and German technical 
writing into incomprehensible English, and the 
Bureau of Reclamation asked the American Trans- 
lators Association to hold a workshop for trans- 
lators so that the Bureau could explain the types 
of materials it needed translated. Through this' 
workshop the Bureau found several professional 
translators who could provide competent transla- 
tion services for reasonable compensation. 

This false economy move of the Federal Govern- 
ment has also had its negative effects on 
foreign- language education in the colleges and, 
especially, in the high schools of this nation. 
Granted that the foreign- language teachers were 
slow to respond to the desire of students to 
learn foreign languages for practical use rather 
than as an entree into the literature of these 



languages, government policies must also share a 
large part of the blame for the decline in 
foreign- language study in this country during the 
past few years. Back in 1973 President Nixon's 
budget wiped out support by the National Defense 
Education Act of some 4500 courses in more than 
80 languages and in all foreign areas -- at a 
savings of less than the cost of one F-lll 
fighter-bomberl [Marshall D. Schulman, The New 
York Times, April 6, 1973, p. 39.] With the 
Federal Government eliminating career opportuni- 
ties and foreign- language programs in the schools, 
indicating by its own example that foreign- 
language study was of little or no importance, is 
it any wonder that young Americans have no 
desire to study foreign languages? 

The United States is unique among the large 
industrial nations of the world in its attitude 
toward translation. There is practically no 
training available for translators in this 
country. Most of our professional translators 
are either self-trained through years of trial 
and error, or they received training in European 
schools for translators and interpreters. Ac- 
cording to the Relac Report, there were no more 
than a half dozen translator trainees in the 
entire U.S. Civil Service in 1974. Prior to 1970 
the only training programs were at Georgetown 
University and at the Monterey Istitute of For- 
eign Studies. Since then some 25 or 30 colleges 
and universities have initiated one ot more 
courses in translation techniques, but the only 
viable, comprehensive training programs that 
have been added for technical translators are 
those at the University of California at Santa 
Barbara (French, German, Spanish), Carnegie -Mellon 
University (French, German, Russian, Spanish), 
Stanford University (German) , the University of 
Puerto Rico (Spanish), St. -Mary-of-the-Woods 
College (French, Spanish), and the Rose Hulman 
Institute of Technology .(German, Russian) . 



"No reliable statistics exist for the amount 
of translation in the United States. " 



Moreover, most of the students in these 
programs (all of them at the Rose Hulman Insti- 
tutute) are not training to become translators 
-- they are future scientists and engineers 
who want to learn how to read foreign research 
in their own fields. (They will still be able 
to read only one or two foreign languages, 
however.) Of a total 162 students enrolled in 
5 of these programs as of October 1976, ap- 
proximately 60 hoped to become translators. 
The same 5 programs graduated 12 students in 
1975, at least 10 of whom were employed in 
non- translation jobs or in positions where 
their language skills were of only minor im- 
portance. 
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In contrast, Canada has 8 training institu- 
tions for translators and interpreters, and 
Western Europe has over 40. There is already 
a critical shortage of competent technical 
translators in this country, and if the Bi- 
lingual Courts Act ever becomes law there will 
be utter chaos with every Spanish- speaking 
janitor pressed into service as a court- inter- 
preter. In a courtroom situation where proper- 
ty, freedom, and even lives may depend upon 



"A national diegraoe" 



accurate translation of not only words but of 
culturally significant gestures, tones of 
voice, facial expression, etc., we cannot af- 
ford to have untrained people acting as inter- 
preters. Translating and interpreting require 
training and experience, NOT just bilinguality. 

No reliable, comprehensive statistics exist 
for the amount of translation performed annual- 
ly in the United States, the amount spent for 
translation, the relative importance of various 
language combinations and of the different 
scientific and technical fields that use trans- 
lations, the number of full-time and part-time 
translators in the country, etc., etc., etc. 
On the other hand, periodic surveys of almost 
every other aspect of business provide current 
statistics on how many hamburgers are consumed 
annually in Kalamazoo or how many pickles one 
can expect to sell in Atlanta. Since 1970 I 
have contacted the Bureau of the Census, De- 
partment of Commerce, Congressmen, Senators 
anyone and everyone I thought might persuade 
the Federal Government to collect such data 
along with the myriad other statistics they 
are compiling continuously all to no avail. 
How can we plan training programs intelligently, 
how can we predict how many translators will be 
needed in 10 years, for example, and in which 
languages and technical fields, without reliable 
data concerning the present state of the pro- 
fession? The American Translators Association 
simply does not have sufficient funds to gather 
such statistics. 

The Soviet Union has these vital statistics. 
The All-Union Center for Translation of Scien- 
tific and Technical Literature and Documentation 
in Moscow reports that its translation output 
doubled between 1970 and 1973, that it increased 
by 150% between 1973 and 1975, and that the 
1976 output was 30% greater than in 1975, to- 
tally some 350 million words. The Ail-Union 
Center is only one of several agencies in the 
Soviet Union. The Chambers of Commerce and 
Industry translated 230 million words in 1975, 
Intourist translates about 17 million words 



annually, and the Central Research Institute for 
Patent Information a little over 7 million 
words. This was a total of more than 500 million 
words in 1975, and other, smaller departments, 
agencies, and research institutions in the Soviet 
Union are reported to have translated several 
times that amount. [V. N. Gerasimov, Translation 
Neu)s 3 Vol. 7, No. 1 (April/May 1977), pp. 1-11.] 

Moreover, since 1975 all translations in the 
Soviet Union have been registered. We have a 
National Translations Center at the John Crerar 
Library in Chicago that makes a valiant effort 
to eliminate duplication and reduce costs by 
making existing translations available for ap- 
proximately the cost of duplication, or by direct- 
ing requestors to the proper source for the 
desired translation. Unfortunately, National 
Science Foundation funds for the NTC were cut off 
a few years ago and the NTC staff was reduced 
from 11 to 4. Over the past four- and -a-half 
years the NTC has' deposited or reported availa- 
bility of 85,891 technical translations, but even 
more were deposited with or reported to the NTC -- 
the staff of four simply could not process any 
more. The NTC estimates that no more than half 
the technical translations made in the U.S. [and 
probably considerably less than half) are reported 1 
to them, due at least in part to lack of funds 
and staff to make the existence of the NTC known 
to everyone involved in the production and utili- 
zation of translations. This, Mr. President, is 
a national disgrace. 

Although I have concentrated on technical 
translation because that is the critical field, 
commercial translation (banking reports, corres- 
pondence, contracts, bills of lading, etc.) is 
playing an increasingly important role as Ameri- 
can business tries to compete in the world market- 
place. Nor should we forget the importance of 
translation in making literature and drama from 
other cultures available to the American public. 
The only training program for literary translators 1 
in the U.S. at this time is at the State Universi- 
ty of New York at Binghamton. 

In your efforts to encourage the study of 
foreign language and cultures I hope you will also 
remember the neglected but very important role of 
the translators of America -- in science and 
technology, in business and commerce, and in the 
humanities. In closing I would like to offer my 
services as an individual and the cooperation of 
the American Translators Association to the Com- 
mission proposed by Congressman Simon. 

Respectfully, 

Royal L. Tinsley, Jr. 
President of ATA 
Associate Professor of German 
University of Arizona 
Tucson, Arizona 85721 
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To the Editor, CRYPTO LOG: 
The note at the end off 
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article "A Linguist Looks at the r Tube fri 
(CRYPTOLOG, March 1978) states that the article 
was "untouched by human hands." Whenever i 
read or hear such statements, I start looking 
for human intervention. I remember, for exam- 
ple, machine-translation output that used to be 
advertised as "completely un-postedited ,f that 
would prove to have hyphens appearing mysteri- 
ously (but correctly!), ot to have proper names 
output in capital letters (such as EYZENKHAUER) 
even though the names had been "unrecognized" 
by the computer. 

From reading the article, I get the impres- 
sion that the right-hand justification is done 
by adjusting the spaces between the words in 
each line, without bothering to use any compli- 
cated hyphenation rules. But I see (last line, 
left column, page 11) "organi-" and (line 6, right 
column, page 11) "justifi-." Who put in those 
hyphens and when? 

Hy Fennwatcher 

The author* of the article replies: 

The word processing system used for my arti- 
cle accomplishes right-margin justification by 
inserting a maximum of two spaces between words 
and works best on normal lines of 60 to 80 
characters. 

Because of CRYPTOLOG' s short lines, the 
word processor occasionally was unable fully to 
perform its right justification on my article 
and, in fact, left a very ragged margin in the 
paragraph that Hy Fennwatcher mentioned. 

Therefore, to improve the appearance of the 
paragraph, my helper interactively (i.e. on 
the CRT screen) hyphenated "organization" and 
let the computer realign the rest of the para- 
graph. Seeing that the results were acceptable 
except for the last three lines, she then 
hyphenated "justification" in the third-from- 
last line and let the computer redo the last 
two lines. 

This intervention would not have been neces- 
sary for a page of standard width, but it is a 
good example of the ease with which text can be 
revised on a CRT-based text handling system. 
The alterations did not require retyping of the 
article or even a page. 
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To the Editor, CRYPTOLOG: 

Yes, Art, CRYPTOLOG ads do get results. In ; 
quarter-page filler in the January 1978 issue 
I listed some "new and improved aids for book- 
breaking <" Within a week after the issue hit 
the streets, the persons listed as contact 
points were bombarded with requests for informa 
tion or copies of the programs. It pays to 
advertise in CRYPTOLOG! 

An unsolicited testimonial from a 
satisfied subscriber V. v. 
(Bookbreaking and Cryptolingui sties 
Coordinator, P16) (U) 



Solution to 
m-ctotiic Ho. 12 

{CRYPTOLOG, March 1977) 

Samfuel S.] Snyder, "[Influence of U.S. 
Cryptologic Organisations on the Digital] 
Computer Industry, National Security 
Agency, Fort George G. Meade, Maryland, 
May 1977, 36 pp., S-217,130, (U) . 

"One of the earliest commercial high-speed 
line printers came about because of NSA sup- 
port, based at least partly on experimentation 
and initiatives by Agency engineers. Like- 
wise, one of the first practical character- 
sensing machines received early [contract] 
encouragement from NSA." 

(U) 
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(F- 18) 


1. 


Honduras 


2. 


Nicaragua 


3. 


Costa Rica 


4. 


Panama 


5. 


Colombia 


6. 


Venezuela 


7. 


Guayana (Guyana) 


8. 


Surinam 


9. 


Guayana francesa 




(French Guiana) 


10. 


Ecuador 


11. 


Peru 


12. 


Brasil (Brazil) 


13. 


Bolivia 


14. 


Paraguay 


15. 


Chile 


16. 


Argentina 


17. 


Uruguay 




Tegucigalpa 
Managua 
San Jose 

Panama (Panama City) 

Bogota 

Caracas 

Georgetown 

Paramaribo 

Cayena (Cayenne) 

Quito 
Lima 

Brasilia 

La Paz/Sucre 

Asuncion 

Santiago 

Buenos Aires 

Montevideo 



April 78 * CRYPTOLOG * Page 21 



P.L. 86-36 



UNCLASSIFIED 



Pl-HAE 79-S3-26295 




THI8 DOCUMENT CONTAINS CODEWORD MATERIAL 

TOP SECRET 



